Code looks good.

Can confirm there's no regression on Windows. @erri120 | @Sewer56, can you please test the implementation on Linux?

Are we sure we want to internalize the ability to launch proton directly? In the app we decided against internalizing and instead using protontricks to handle running commands because it sets up everything for us: https://github.com/Matoking/protontricks/blob/7ee7ee0a612064e3bb722de7b3ad7036d3bbfd3c/src/protontricks/util.py#L444

Are we sure we want to internalize the ability to launch proton directly? In the app we decided against internalizing and instead using protontricks to handle running commands because it sets up everything for us: https://github.com/Matoking/protontricks/blob/7ee7ee0a612064e3bb722de7b3ad7036d3bbfd3c/src/protontricks/util.py#L444

Protontricks is also more likely to closely follow Proton developments that might otherwise break an internalized feature.

Fine by me. Same comment as the two above; but not a big deal for now.
There haven't been any major breaking changes I can think of in a while, though, so for now this is fine.

Looking at this reminds me that last I tried, building a static protontricks was a PITA, nevermind the manual maintenance of version updates afterwards.

As far as things go longer term. Supporting other stores may require the likes of umu; but that's not set in stone. e.g. If we go the route of instead supporting Heroic again for GoG, they'd be doing that for us on their end. We just invoke via Heroic as usual, like with NMA.

I built the linux-steam-finder branch on ultramarine linux. (fontconfig-devel needed to be installed manually). I successfully launched Fallout 4 through steam/proton (native steam package, not flatpak) from Vortex's play button. I have a 20 second video if it's acceptable to attach it here.

Vortex detected Fallout 4's game path just fine, however related paths are checking for things like Fallout4.ini and Fallout4Prefs.ini in "home/{username}/Documents/..." instead of the game's respective wine prefix. For reference, in my case fallout 4's prefix would be in "/home/xela/.steam/steam/steamapps/compatdata/377160/pfx/". I'm not sure if " Verify Steam path detection" is just referring to the game folder itself or if this is included, but I thought I'd mention it.

Are we sure we want to internalize the ability to launch proton directly? In the app we decided against internalizing and instead using protontricks to handle running commands because it sets up everything for us: https://github.com/Matoking/protontricks/blob/7ee7ee0a612064e3bb722de7b3ad7036d3bbfd3c/src/protontricks/util.py#L444

Whatever we do, I'd rather not have additional setup steps for users. Is protontricks installed by default on SteamOS? If not can't we just launch games using whatever method Steam uses?

I'd like to avoid having to mod the mod manager in order to have things work for users. Or perhaps we can have protontricks included in flatpack (maybe that's crazy talk) or installed as a prerequisite for the Vortex flatpack? Whatever we do, I really just want a download the app and it works out-of-the-box.

Is protontricks installed by default on SteamOS

No.

If not can't we just launch games using whatever method Steam uses?

The Steam browser protocol allows you to launch games through Steam but it doesn't allow you to run arbitrary commands.

I'd like to avoid having to mod the mod manager in order to have things work for users. Or perhaps we can have protontricks included in flatpack (maybe that's crazy talk) or installed as a prerequisite for the Vortex flatpack? Whatever we do, I really just want a download the app and it works out-of-the-box.

Flatpaks can't depend on another flatpak by design. App-to-app dependency chains are deliberately avoided because that'd break the sandbox. The common approaches to this are

1. to vendor protontricks, or
2. rely on a pre-installed version of protontricks

I'm happy that we just internalize it and get this PR wrapped up. Seweryn is going to be working on Flatpak next week.

Hey, so for what it's worth a lot of the protontricks can be fully replaced with winetricks and just using the GitHub binary raw file. It's late so I pulled this directly from Claude as an example of the things that I do to ensure mo2 integration with steam.

rundown.md

I know its written in rust, but you should be able to get the idea if you want to even take a look at it in the first place. NaK I just thought I'd drop by with some ideas. A lot of the winedlloverrides can be written to a registry file and applied via proton itself removing the need for launch options.

If I had the chance to support or request a feature, my only request would be having an option to chose your own location for a prefix. Because I'd love to support the Linux port of vortex but it wouldn't really be possible if I can't get a dedicated prefix for it. (And yes spooky sloppy ai for my personal projects lol)

Edit: And for linux game detection, any reason why you couldn't just rewrite support for GameFinder to be incorperated into vortex?

There are some glaring omissions in the implementation.

• It doesn't search for proton in the system-wide directory i.e. /usr/share/steam/compatibilitytools.d
• It doesn't handle standalone <compatibility_tool>.vdf files in any of the search locations. https://github.com/ValveSoftware/Proton/blob/proton_10.0/compatibilitytool.vdf.template
• It doesn't run proton in the expected Steam Linux Runtime environment. The required runtime appid is available in toolmanifest.vdf. If the attribute is missing, it means that no runtime should be used to run this tool. https://github.com/ValveSoftware/Proton/blob/proton_10.0/toolmanifest_runtime.vdf
• The proton detection is based on the name of the proton script, which is mutable. toolmanifest.vdf contains identifying information in compatmanager_layer_name attribute. This is minor though, as the script's name is unlikely to change.
• Running tools that need to access the game process's memory can be tricky, using the same prefix is not enough. Since proton and thus games run in a container, they use a different namespace, which will block any such tools from working. One way to handle it would be to use pv's debugging facilities.

More documentation:

• https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/steam-compat-tool-interface.md
• https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#inserting-debugging-commands-into-the-container

There are some glaring omissions in the implementation.

• It doesn't search for proton in the system-wide directory i.e. /usr/share/steam/compatibilitytools.d
• It doesn't handle standalone <compatibility_tool>.vdf files in any of the search locations. https://github.com/ValveSoftware/Proton/blob/proton_10.0/compatibilitytool.vdf.template
• It doesn't run proton in the expected Steam Linux Runtime environment. The required runtime appid is available in toolmanifest.vdf https://github.com/ValveSoftware/Proton/blob/proton_10.0/toolmanifest_runtime.vdf
• The proton detection is based on the name of the proton script, which is mutable. toolmanifest.vdf contains identifying information in compatmanager_layer_name attribute. This is minor though, as the script's name is unlikely to change.

More documentation: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/steam-compat-tool-interface.md

I was just giving some information as a lot of this can easily be modified/handled.

And as for the SLR I have found no issues not using for prefix creation, with users using flatpak or native steam. At least in my testing on NaK. Again I was just giving my thoughts and opinions, as the winetricks method is something Omni uses in Jackify as well.

@SulfurNitride I believe you quoted my comment by mistake. I am referring to the general implementation of this PR, not to your suggestion.

As for not using the SLR, well, it is being used for a reason by Steam, no matter how many issues you encounter or not, you cannot be certain that it will work for everyone.